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(57) Abstract 



1 



A highly secure, virus resistant, tamper resistant, object oriented, data processing system (1) for depositing, withdrawing and 
communicating electronic data between one or more individual and/or networked computers (2, 2a, 2b, 3, 3a) comprising one or more 
computers for processing electronic data including one or more shared electronic storage devices (6, 7, 8, 9, 10) for the temporary and/or 
permanent storage of said electronic data, each of said computers (2, 2a, 2b, 3, 3a) including custom configurable system programs (100, 
200, 300, 400, 500, 600, 700) for asynchronous depositing, withdrawing and communicating said electronic data to commonly shared 
electronic storage devices, and said programs permitting data archival, accountability, security, encryption and decryption, compression and 
decompression, and multi-processing capabilities. 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international 
applications under the PCT. 



AT 


Austria 


GB 


United Kingdom 


MR 


Mauritania 


AU 


Australia 


GE 


Georgia 


MW 


Malawi 


BB 


Barbados 


GN 


Guinea 


NE 


Niger 


BE 


Belgium 


GR 


Greece 


NL 


Netherlands 


BF 


Burkina Faso 


HU 


Hungary 


NO 


Norway 


BG 


Bulgaria 


IE 


Ireland 


NZ 


New Zealand 


BJ 


Benin 


IT 


Italy 


PL 


Poland 


BR 


Brazil 


JP 


Japan 


FT 


Portugal 


BY 


Belarus 


KE 


Kenya 


RO 


Romania 


CA 




KG 


Kyrgystan 


RU 


Russian Federation 


CF 


Central African Republic 


KP 


Democratic People* a Republic 


SD 


Sudan 


CG 


Congo 




of Korea 


SE 


Sweden 


CH 


Switzerland 


KR 


Republic of Korea 


SI 


Slovenia 


CI 


Cote d'lvoire 


KZ 


Kazakhstan 


SK 


Slovakia 


CM 


Cameroon 


U 


Liechtenstein 


SN 


Senegal 


CN 


China 


LK 


Sri Lanka 


TD 


Chad 


cs 


Czechoslovakia 


LU 


Luxembourg 


TG 


Togo 


cz 


Czech Republic 


LV 


Latvia 


TJ 


Tajikistan 


DE 


Germany 


MC 


Monaco 


TT 


Tttnidodapd Tobago 


DK 


.Denmark 


MD 


Republic of Moldova 


. UA 


Ukraine 


ES 


Spain 


MG 


Madagascar 


US 


United States of America 


FI 


Finland 


ML 


Mali 


uz 


Uzbekistan 


FR 


France 


MN 


Mongolia 


VN 


Viet Nam 


GA 


Gabon 













PCT/US93/11865 



WO 94/14127 



-1- 



1 



Specification 



2 



3 



ASYNCHRONOUS SYSTEM AND METHOD FOR ELECTRONIC 



4 



DATA MANAGEMENT, STORAGE AND COMMUNICATION 



5 



6 



FIELD : 



7 



The invention relates to a computerized system and 



8 method for asynchronous storage, retrieval, and 

9 communication of electronic data on a peer to peer basis. 
10 

11 BACKGROUND: 



13 electronic data management, storage and communication 

14 systems and methods, particularly network systems, is a 

15 common data storage unit which is accessible by all users 

16 on a synchronous basis for storage, retrieval, and 

17 communication of data. The synchronous nature of these 

18 systems poses numerous problems. 

19 One such problem is that to prevent simultaneous 

20 access to the same record, i.e., the same physical space 

21 on the data storage and retrieval device, software 

22 programmers must incorporate file, record, or field 

23 locking means into the software which prevent the writing 

24 and reading to the same record at the same time- This 

25 vastly complicates the writing of the software and 

26 functionally slows access time. 

27 Another serious disadvantage of synchronous 

28 electronic data management, storage, retrieval and 

29 communication systems is that the system may "lock-up" 

30 rendering the common data storage and retrieval device 

31 inaccessible and unusable until the system is restored to 

32 its operable state. Because most network systems are 

33 dependent on "sending" information to a computer that is 

34 assumed to always be on-line to receive the information, 

35 lock-up may occur when: a) computers in the network go 

36 off-line or come on-line without proper logging-on or 

37 logging-off procedures; or b) an individual computer 

38 crashes or its power fails; or c) the operator 

39 inadvertently terminates the network communications 



12 



A primary and vital aspect of existing computerized 
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1 program to run an applications program. These are just a 

2 few of the many ways in which individual computers linked 

3 in a network can go off-line, causing the entire network 

4 communications to lock-up. And because most network 

5 systems cannot easily share information with other 

6 networks of differing protocols, users tend to move to 

7 bigger and bigger network systems. The bigger the 

8 network, the worse the lock-up problem. 

9 Another problem is that there is no universal method 

10 to store data in a common data storage and retrieval 

11 device from the many different applications programs, nor 

12 is there any way for multi-tasking applications to share 

13 information in an asynchronous manner and at the same or 

14 near real time. 

15 Another problem is the integrity of the data when 

16 passed from computer to computer or from network to 

17 network. Most network systems cannot assure complete 

18 transmission of data. It is particularly difficult to 

19 pass data between different networks, especially if the 

20 network systems use differing protocols. 

21 Another problem is user tracking. User entry and 

22 exit trails are extremely hard to reconstruct after there 

23 has been any access, authorized or unauthorized, to the 

24 common data storage and retrieval device. 

25 Another severe problem of a common data storage and 

26 retrieval device is that it is susceptible to user 

27 tampering or virus infection, both of which can result in 

28 altered, scrambled or deleted data. The susceptibility of 

29 user tampering and viral infection often requires 

30 elaborate and expensive countermeasures such as password 

31 systems and anti-viral software. 

32 Another problem is that data cannot be transmitted 

33 between networked computers in encrypted form. 

34 Another problem is that most network systems require 

35 a computer having large computing power and a large 

36 capacity data storage device to act as dedicated host or 
37. server to run . the network, operating programs. Then, 

38 individual workstations or computer stations '( "clients") 

39 must be hard-wired to the server. In addition, with many 
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1 client-server based systems, two different types of 

2 computer programs are required, one for server operations 

3 and one for client data manipulation. This further 

4 complicates the writing of programs and slows access time. 

5 Accordingly, there is a need for a computerized 

6 system for the management, storage, retrieval and 

7 communication of electronic data that is asynchronous in 

8 nature and which system overcomes the inherent problems 

9 associated with the existing synchronous systems as 
10 described above. 

11 

12 THE INVENTION 

13 TERMS: 

14 It is to be understood that any reference to the 

15 below listed terms shall have the corresponding meaning 

16 provided: 
17 

18 Object: means any binary data file, including but not 

19 limited to, documents, programs, graphics, voice mail, 

20 faxes, computer Aided Design (CAD) files, and Binary Large 

21 Objects (BLOB's), and the like, as they are traditionally 

22 and broadly understood, as well as any other object that 

23 is desired to be written to a data storage device, area, 

24 or location. In the disclosure herein, reference to data 

25 storage device, area, or location or the act of reading or 

26 writing may interchangeably refer to "in" or "on". Thus, 

27 "writing on" or "writing in" means the same. 
28 

29 Temporary Object: means an object having an expiration 

30 date; i.e., in-process objects which are stored 

31 temporarily in the electronic data storage means of an 

32 ObjectBank system. 
33 

34 permanent Object: means an object having no expiration 

35 date; i.e., an object that will be stored forever on an 

36 electronic data storage device compatible with an 

37 ObjectBank System. 
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1 Objectsafe: means a specified physical data storage area 

2 of a data storage device including, but not limited to f 

3 hard disks, floppy disks, magnetic tape, magnetic drum, 

4 bubble memory, stringy tape, digital audio tape ("DAT") , 

5 VCR tape, laser disks, magneto-optical disks, CD-ROMs, and 

6 laser cards. 

7 

8 Objectvault: means a dedicated computer having an 

9 Objectsafe which has sufficient data storage capacity to 

10 store all objects of all ObjectSafes on the objectwire 

11 Network. 

12 

13 ObjectTeller: means an OLE-aware and OLE-accessible 

14 computer program having user customizable function means 

15 to deposit and withdraw ("retrieve") objects to and from 

16 ObjectSafes and to conduct status checks of deposits and 

17 withdrawals . 



18 
19 
20 



ObjeotWire: means a computer program having user 
customizable function means for communications, i.e., 

21 polling and retrieving objects, from other individual or 

22 networked computers each having an Objectwire program. 



23 
24 



Objectwire network: means the architecture of all 
25 computers compatible with an ObjectBank system, i.e., any 



26 



28 



one or more computers linked together by having an 



27 ObjectTeller and Objectwire program installed. 



29 ObjectBank system: means any one or more computers having 

30 installed an ObjectTeller and Objectwire program and a 

31 system architecture configuration comprising an objectsafe 

32 and/or Objectvault, MED and Out Box. A computer having an 

33 ObjectBank System may be referred to as an ObjectBank 

34 System computer. 
35 

3 6 Message Exchange Database ("MED") : means a defined 

37 . physical electronic data storage area of an Objectsafe or 

38 Objectvault accessible via the ObjectTeller program or 

39 other OLE-aware application program for the purpose of 





PCT/US93/11865 



WO 94/14127 



-5- 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 



depositing and withdrawing temporarily stored objects for 
the purposes of communicating messages requesting an 
object be stored in a target Object Safe or ObjectVault or 
requesting an object be retrieved from a target ObjectSafe 
or ObjectVault. 

ObjectBank Manager: means a specified user responsible 
for the operation, care and maintenance of a computer or 
computer network having an ObjectBank System, 

out Box: means a temporary electronic data storage area 
of an ObjectSafe for the posting of objects via the 
ObjectTeller program to be retrieved and stored to one or 
more other computer's ObjectSafes or ObjectVault on the 
ObjectBank Network. 

Index Card ("IC") : means a permanently stored customizable 
and modifiable electronic index data file of every object 
of the ObjectBank System having the following data fields: 
object type, date/time, IC identification code, parent IC 
identification code, created by, key words (four), 
abstract, object source path; and, each index data file 
having user selected features for data encryption, data 
compression, password access, public or private list 
access, and IC visibility. 

Index Card Template: means an electronic template or 
"mask" having a default configuration of an uncompleted or 
"blank" Index Card and which template is user customizable 
and which default or customized template is used for the 
creation of an object Index Card. 

OLE: means "object linking and embedding" as is commonly 
known in the field of the art. 

DRAWINGS: 

Pig. l is a schematic diagram of the architecture of. 
a plurality of computers having an ObjectBank System of 
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1 the invention comprising an ObjectWire Network 

2 configuration; 

3 Pig. 2 is a flowchart diagram of the Configuration 

4 process routine of the ObjectTeller program of the System 

5 invention; 

6 Pig. 3 is a flowchart diagram of the Deposit process 

7 routine of the ObjectTeller program of the System 

8 invention; 

9 Pig. 4 is a flowchart diagram of the Withdrawal 

10 process routine of the ObjectTeller program of the System 

11 invention; 

12 Pig. 5 is a flowchart diagram of the Status process 

13 routine of the ObjectTeller program of the System 

14 invention; 

15 Pig. 6 is a flowchart diagram of the Configuration 

16 process routine of the ObjectWire program of the System 

17 invention; 

18 Pig. 7 is a flowchart diagram of the Polling process 

19 routine of the ObjectWire program of the System invention; 

20 and 

21 Pig. 8 is a flowchart diagram of the Withdrawal 

22 process routine of the ObjectWire program of the System 

23 invention. 
24 

25 SUMMARY: 

26 The invention is directed to an asynchronous 

27 electronic data management, storage, retrieval and 

28 communication system and method compatible with any multi- 

29 tasking operating system. The overall system is called an 

30 "ObjectBank System." The ObjectBank System comprises a 

31 user interface program called the "ObjectTeller" program, 

32 a communications program called the "ObjectWire" program, 

33 (both programs written in "C" language and capable of 

34 being written by one skilled in the art of computer 

35 programming) , and computer system architecture including 

36 a standard industry computer processor, input/ output 

37 devices and at least one primary defined physical data 

38 storage area for "objects" called the "ObjectSafe" qr 

39 "ObjectVault. " Objects can be any type of binary data 
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file. Each object is index referenced by use of 
electronic "index cards" and stored in an ObjectSafe for 
retrieval upon request using the ObjectTeller Program and 
communication among computers by the ObjectWire Program. 
5 All Permanent Objects of all ObjectBank System computers 
on the ObjectWire Network may be stored in an archival 

7 ObjectSafe which is then called an objectVault. There is 

8 no physical difference between an ObjectSafe and an 

9 ObjectVault other than an ObjectSafe permanently stores 

10 select objects whereas an ObjectVault permanently stores 

11 all objects from all ObjectSafes on an ObjectWire Network. 
12 

13 objective of the Ry^em Invention: 

14 The objective of the ObjectBank System is to provide 

15 a method means for electronic data management, storage, 

16 retrieval and communication of data stored in a 

17 universally compatible ASCII format in at least one 

18 central storage device (ObjectSafe or ObjectVault) and 

19 shared in an asynchronous manner on a peer to peer basis 

20 with other ObjectBank System computers. Each object in 

21 the ObjectBank System is indexed and stored to a user 

22 selected target ObjectSafe and/or ObjectVault. Once 
stored, objects are never modified, overwritten or 
deleted, but are only copied and the copies shared with 
other users. Objects are shared between users by message 

26 request using a Message Exchange Database ("MED") Upon 

27 the message request by other users for the sharing of a 
particular object (or all objects) from a specified (or 
all computers) on the ObjectBank Network, the ObjectBank 
Manager of the target ObjectSafe copies the requested 
object(s) and places the object(s) in an "Out Box" for 
"pick-up" (transmission) via the ObjectWire program by the 
requesting users. Since objects are only copied from the 
ObjectSafe or ObjectVault, the stored objects are guarded 
against any modification or tampering and the ObjectSafe 
and/or ObjectVault is protected against virus infection 
because no object stored is ever "run" which execution 

38 would typically provide the mechanism for infection by or 

39 replication of a virus. The ObjectBank System may also 



23 
24 
25 



28 
29 
30 
31 
32 
33 
34 
35 
36 
. 37 
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1 provide data protection by periodically reminding the 

2 ObjectBank Managers to permanently store their important 

3 Temporary Objects and delete multiple copies of Temporary 

4 Objects. The ObjectBank System is specially designed to 

5 pass information between computers on the ObjectWire 

6 Network with near 100% accuracy. An Index Card for each 

7 object maintains at least one sequential, historical trail 

8 of its origin. Thus, each object's Index Card will have 

9 a reference record of its origin and of the "family tree" 

10 of related objects, i.e., the physical addresses of each 

11 parent and child of an object. Thus, Index Cards help 

12 speed access to objects, record a trail of copies of 

13 objects that are deposited or retrieved, record who made 

14 the deposits or requests, and record what other ObjectBank 

15 System computers have copies of objects and Index Cards. 

16 Like any other Permanent Object, completed Index Cards are 

17 stored in the ObjectSafe or ObjectVault and copies may be 

18 made and transferred to other users on the ObjectWire 

19 Network. 
20 

21 Interconnect ivitv of the System Invention : 

22 The ObjectBank System of this invention is 

23 particularly adapted for use with computers which may be 

24 linked via modem or network using currently available 

25 network programs, such as Lantastic and Novell. To be 

26 compatible with the ObjectBank System, however, each stand 

27 alone computer or each networked computer system requires 

28 its own ObjectTeller and ObjectWire programs. Together, 

29 the ObjectBank System computers comprise an ObjectWire 

30 Network. Communications between computers on the 

31 ObjectWire Network is on a "receive alone" basis, i.e., 

32 there is no "sending" of any data or object to a target 

33 address. The ObjectWire program is configured by a user 

34 to look for and request certain types of objects by 

35 designated search criteria. The ObjectWire program time 

36 sequentially "polls" via modem or network a Message 

37 Exchange Database ("MED") of other ObjectNetwork computers 

38 for the designated type 'of* object fitting the search 

39 . criteria. If the designated type of object is made 
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1 available for copying by a ObjectBank Manager, i.e., 

2 placed in an Out Box, it is transmitted to the requesting 

3 user by the requesting user's ObjectWire program* Because 

4 each computer of the ObjectBank System only receives only 

5 copies of objects made available by other users on the 

6 ObjectWire Network, there is no "sending" of data and 

7 therefore no mechanism to cause the ObjectBank System to 

8 lock-up. Thus, computers which remain on the ObjectWire 

9 Network can continuously receive available (stored) 

10 objects and in any order from any computer system which 

11 remains on the ObjectWire Network. If any computer goes 

12 off the network through a power outage, computer hardware 

13 or software defect, user error, the ObjectBank System of 

14 operation is not affected. Each ObjectBank System 

15 compatible computer will continue to poll for requested 

16 objects and hold any object retrieval or storage requests 

17 until the target computers are reconnected. 

18 Computers in the Ob j ectWire Network can be 

19 interconnected via modem, Local Area Network (LAN) which 

20 involves linkage of in-house computers, or Wide Area 

21 Network (WAN) which involves networks linked to other 

22 networks. The ObjectWire program has the capability to 

23 log on sequentially to successive networks using different 

24 network software and protocols, and to process the 

25 respective storage and retrieval message requests. 

26 Because objects are "picked up" by the ObjectBank System 

27 rather than "sent," the system of this invention is 

28 particularly conducive to an architecture wherein the 

29 ObjectBank System connects to multiple networks 

30 sequentially and picks up from each Message Exchange 

31 Database (MED) any storage or retrieval message requests 

32 to perform on that network or pass along to an ObjectSafe 

33 on another network before disconnecting and connecting to 

34 the next network. This allows users to share objects 

35 easily in an asynchronous manner among several non- 
36 compatible network systems. 
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1 Rules of the System and Method Invention ; 

2 Two basic rules of the ObjectBank System and method 

3 apply: First, no computer may write to any storage device 

4 of any other computer on the ObjectWire Network. Second, 

5 permanently stored objects are never modified, over- 

6 written or deleted. Therefore, only copies of stored 

7 objects are ever transmitted to other computers on the 

8 ObjectWire Network. 
9 

10 Encryption and Compression of Objects ; 

11 For data security and efficiency of operation, object 

12 encryption and compression may be employed. In the best 

13 mode of operation, the default configuration of the 

14 ObjectTeller program is to encrypt and compress all 

15 objects for permanent storage as well as transmission to 

16 other users via the ObjectWire program. However, the 

17 ObjectBank Manager has the option of specifying that a 

18 particular object or all objects not be encrypted or 

19 compressed. 
20 

21 Access Authorization : 

22 In addition to object encryption and compression, the 

23 ObjectBank System maintains a multi-leveled access 

24 authorization structure for users, messages, index cards, 

25 and objects. When the user accesses the ObjectBank 

26 System, the user's identification code and password is 

27 verified by the ObjectTeller Program to determine whether 

28 that user is authorized to access the object stored in 

29 that ObjectSafe. The ObjectTeller configuration files 

30 include the list of authorized users to store and/or 

31 retrieve all or particular objects. Modifications to the 

32 list are appropriately protected so that only authorized 

33 persons (e.g., the ObjectBank Manager) can add or delete 

34 user names. There are three levels of access to objects: 

35 (1) if the object is available for anyone on the 

36 ObjectWire Network to copy, then the access is 

37 "Public"; 
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1 (2) if there is a distribution list of authorized 

2 users to particular objects, then the access is 

3 "Restricted"; and 

4 (3) if there is only the original user on the 

5 authorization list, then the access is "Private." 
6 

7 Index Cards ; 

8 All ObjectBank System transactions are recorded on an 

9 object reference Index Card which is created automatically 

10 when an object is stored to an ObjectSafe or ObjectVault. 

11 Index Cards provide a rapid reference classification means 

12 for retrieval of objects from an ObjectSafe or 

13 ObjectVault. Index Cards also provide a means for 

14 determining the genealogy of object requests, storage, and 

15 retrievals. In addition, Index Cards provide the means by 

16 which the user determines: (1) whether or not the object 

17 is to be encrypted and/ or compressed; (2) the password; 

18 (3) the access level (i.e., public, restricted, or 

19 private); (4) the access list of authorized users; (5) 

20 whether or not the Index Card will be "visible" (i.e., 

21 displayed) to other users; (6) up to four "key words" of 

22 the object to be used as index search terms; and (7) an 

23 abstract (summary) of the subject content of the object. 
24 

25 Each ObjectBank System keeps its own set of Index 

26 cards and records, in date/time sequence, of all requests 

27 for objects, all retrievals obtained or denied, all 

28 deposits offered and/or accepted by the ObjectSafe. The 

29 ObjectBank System maintains indexes to help speed access 

30 to its objects, to record a trail of copies of objects 

31 that are deposited or retrieved, to record who made the 

32 deposits or requests, and to record what other computers 

33 have copies of objects and indexes. In addition, users 

34 may create via an Index Card Template additional reference 

35 Index Cards of the object, such as: WordPerfect documents 

36 by "Author" and "Subject"; Lotus files by the contents of 

37 cell "Al"; Dbase files by "Field" within "Record" ; CAD 

38 files by "Changed-By," etc. A user may build Temporary 

39 Index Cards of his and other user's objects for a specific 
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1 search. By way of example, a "fuzzy" search may be 

2 conducted by searching for certain key words on Index 

3 Cards. In addition, searches may be made directly of the 

4 objects in the Objectsafes, if the Index Card information 

5 is not complete or sufficient. 

6 Index Cards of the users objects are stored in the 

7 users ObjectSafe. Index Cards of objects stored on other 

8 Objectsafes may be also be stored if selected by the user. 

9 Typically, the user's computer ObjectSafe has more limited 

10 storage space and the user will not want to store all 

11 Index Cards from all the Objectsafes. The user can 

12 configure his ObjectBank System to keep only selected 

13 Index Cards related to specific topics. However, if the 

14 user wishes to see other types of Index Cards, he can 

15 configure the ObjectWire program to request and retrieve 

16 Index Cards relating to a particular subject from other 

17 Objectsafes. 

18 Like all objects, all Index Cards for all Objectsafes 

19 on the ObjectWire Network may be stored in the 

20 ObjectVault. Index Cards are never deleted. If they are 

21 updated, the prior Index Cards are always available for 

22 review. Periodically, Temporary Index Cards are stored as 

23 Permanent Objects is an ObjectVault for safekeeping. 
24 

25 conf iaursfion of obieci-R»nk- system: 

2 6 An ObjectBank System is configured via both the 

27 objectTeller program and the ObjectWire program. The 

28 ObjectTeller program contains configuration routines used 

29 to install and configure the ObjectBank System on each 

30 computer and to create an ObjectSafe or ObjectVault. The 

31 configuration process includes the steps of: 

32 1. Assigning a unique ObjectSafe Identification Code 

3 3 to the computer for use on the ObjectWire Network; 

34 2 . Designating storage rights, i.e. identifying 

35 whether this ObjectSafe will permit storage of either 

36 Permanent or Temporary Objects, both, or neither (in which 
,37 case users could only access, information stored in other 

' 38 Objectsafes over the ObjectWire Network); 
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1 3. Setting which physical storage device (s) can be 

2 used as the Object Safe; 

3 4. Setting the maximum size for the ObjectSafe; 

4 5. Determining whether other users will be allowed 

5 to store objects in the ObjectSafe; 

6 6. Assigning to the User List user identification 

7 codes, access levels and passwords which permit users to: 

8 a. retrieve from the ObjectSafe; 

9 b. retrieve from other selected ObjectSafes; 

10 c. store to the ObjectSafe; 

11 d. store to other selected ObjectSafes; 

12 e. perform "housekeeping functions" — including 

13 assigning at least one user as the "ObjectBank Manager" 

14 who will be capable of transferring Permanent Objects from 

15 the ObjectSafe, change access levels and user passwords, 

16 etc.; 

17 7. Specifying the software and hardware 

18 configuration of the computer to provide other ObjectBank 

19 System users an indication of whether or not their 

20 computers can use a certain object; 

21 8. Setting up the default Index Cards that will be 

22 used for the various types of objects that will be stored 

23 in the ObjectSafe and permit the user to build new default 

24 Index Cards; and 

25 9. If this is the first time the ObjectBank System 

26 is used on the computer, the creation of hidden 

27 subdirectories and the verification of connections to the 

28 Objectwire Network. 

29 The Objectwire program also contains configuration 

30 routines which include the process of: 

31 i. Determining which Index Cards from other 

32 ObjectSafes will be stored in its ObjectSafe; and 

33 2. Specifying which other ObjectSafes shall and 

34 shall not be polled on the Objectwire Network and the 

35 access method (e.g., network card, modem phone number, 
3 6 password , etc . ) . 
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1 Housekeeping Functions : 

2 There are a number of Housekeeping functions of the 

3 ObjectTeller program of the Objectbank System. These 

4 functions include the following: 

5 1. Backup/Restore Objects. This function is used to 

6 backup the objects stored on the ObjectSafe to another 

7 storage device or to restore the objects stored on the 

8 ObjectSafe from another storage device. 

9 2. Rebuilding Index Cards. This function is used to 

10 rebuild Index Cards from the original object stored in the 

11 ObjectSafe if the Index Cards have been corrupted. 

12 Certain Index Card information is written directly on the 

13 object as a header label when the object is compressed for 

14 storage in the ObjectSafe. This header information is 

15 sufficient to rebuild most of the Index Card if it is 

16 destroyed. This function is also used to build temporary 

17 indexes for a fuzzy search by a user; for example, 

18 searching all Index Cards or all objects for the phrase 

19 "cartridge valve" occurring within a search boundary of 10 

20 words from the phrase "competitor". This function is also 

21 used to set up the default Index Cards that will be used 

22 by this ObjectSafe for various types of objects, 

23 3. Move Objects to Other Physical Storage Devices. 

24 This function is used to move objects from one ObjectSafe 

25 to another or ObjectVault, to move objects from one 

26 physical storage location to another within an ObjectSafe, 

27 to move objects from Temporary to Permanent storage, or to 



28 move objects to a "NULL" device. Upon the execution of a 

29 move operation, the object will no longer reside in the 

30 original source ObjectSafe location, although the Index 

31 Card will remain indicating that the object was in that 

32 ObjectSafe location and moved to another ObjectSafe 

33 location. Permanent Index Cards are never deleted and 

34 therefore there will always remain a record of the prior 

35 and subsequent locations of moved objects. 



36 4. Deleting Objects. 

37 a. . At any time a user may delete Temporary 

38 Objects from the ObjectSafe and suggest that Temporary 

39 Objects be deleted from other users ObjectSafes. 
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1 Permanent Objects are never completely "deleted," but are 

2 moved to another storage device to free up storage space. 

3 The only method to actually, physically "delete" a 

4 Permanent Object from the ObjectSafe or ObjectVault is to 

5 purposefully move the object to a "NULL" device. 

6 b. The ObjectBank Manager may delete any user's 

7 Temporary Objects from the ObjectSafe and move any 

8 Permanent Ob j ects to a NULL Device . There may be a 

9 different ObjectBank Manager for each ObjectSafe. If one 

10 or more ObjectVaults have been created, each ObjectVault 

11 must have at least one ObjectBank Manager who has physical 

12 access to the ObjectVault computer. An ObjectBank Manager 

13 or user may only perform these "delete" functions from the 

14 local keyboard attached to the ObjectSafe or ObjectVault 

15 computer when logged off the ObjectWire Network. 

16 c. Anytime that objects are deleted from an 

17 ObjectSafe, the Index Cards are updated with the 

18 information about the deletion. Even if Permanent Objects 

19 are "deleted" by moving the object to a NULL Device, Index 

20 Cards remain in the ObjectSafe as a permanent record of 

21 the object's prior existence. 

22 5. Packing Objects After Deletions. When the object 

23 is moved from the ObjectSafe, the ObjectBank System will 

24 pack the remaining objects to optimize physical storage 

25 space usage. 

26 6. ObjectBank. System Start-up /Shut-down. The 

27 ObjectBank System programs contain a Start-up/ Shut-down 

28 routine for entering and exiting the ObjectBank System 

29 (i.e., ObjectTeller and ObjectWire programs). The user 

30 may use this function to start-up or shut down the 

31 ObjectBank System completely, or just turn on or off 

32 selected functions of the ObjectBank System. Upon the 

33 execution of the routine, the ObjectWire Program will poll 

34 the Message Exchange Databases of other ObjectSafes on the 

35 ObjectWire Network to determine if there are any message 
3 6 requests or works-in-process. 
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1 operation of the ObjectBank S ystem Method: 

2 In typical operation, the objectBank System method of 

3 this invention functions as follows: 
4 

5 Depositing of Objects: When a user determines that an 

6 object is to be deposited ("stored") in a selected target 

7 ObjectSafe or ObjectVault, a user completes an Index Card 

8 identifying the object to be deposited. The Index Card is 

9 generated and completed by either executing the 

10 ObjectTeller program functions directly or indirectly 

11 through an OLE aware application program (which 

12 automatically executes the ObjectTeller program functions 

13 upon the execution of a certain application command such 

14 as "Save," for example). Once the Index Card is 

15 completed, the object is encrypted, compressed, and copied 

16 into the user's ObjectSafe. If the object is to be 

17 deposited to another users ObjectSafe or to an 

18 ObjectVault, the encrypted and compressed object is copied 

19 to the user's Out Box and a message request that the 

20 object be deposited in the target ObjectSafe or 

21 ObjectVault is placed in the user's Message Exchange 

22 Database. The object is left in the user's Out Box for 

23 pick-up ("copying") at some near future time by the target 

24 ObjectWire Program of the target ObjectBank System. 

25 Each ObjectWire program of each ObjectBank System 

26 polls each Message Exchange Databases of the various 

27 computers on the ObjectWire Network. This polling may be 

28 on a regular, timed interval basis, or it may be done on 

29 a learned, frequency-of -use-basis. When an ObjectWire 

30 program detects a message request to deposit an object to 

31 its System's ObjectSafe or ObjectVault, it verifies that 

32 the user is authorized to store objects in its ObjectSafe 

33 or ObjectVault, then copies to its ObjectSafe or 

34 ObjectVault the object left for pick-up in the source 

35 user's Out Box. At that time, a running historic record 

36 is updated and put on an Index Card and placed in the 

37 target ObjectBank System's Out Box for pick up by the 

38 source of the message request and ail other ObjectBank 
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1 Systems. In this manner, all ObjectBank Systems are aware 

2 of all completed ObjectBank transactions. 



4 withdrawal of Objects: When an ObjectBank system user 

5 wants to withdraw ("retrieve") a particular object from an 

6 ObjectSafe or Object Vault, the user executes the 

7 ObjectTeller Program withdrawal routine which produces an 

8 Index Search Card to be completed for the purpose of 

9 searching for and finding the desired object's Index Card. 

10 If Index Cards are to be searched on other ObjectBank 

11 System computer's, a retrieval request message directed to 

12 the target ObjectBank System is place in the Message 

13 Exchange Database for pick-up by the target System (s) . 

14 The target ObjectBank System's ObjectWire program polls 

15 each Message Exchange Database, detects the request 

16 message, searches for the object Index Card requested, 

17 determines that the requesting user is authorized to 

18 retrieve the object, locates the object, makes a copy, 

19 places it in its Out Box for pick-up and places a message 

20 in its Message Exchange Database that it is ready for 

21 pick-up. The requesting user's own ObjectWire Program 

22 cyclically polls the target ObjectBank Systems Message 

23 Exchange Database. When the ObjectWire program detects 

24 that the object requested is in the target ObjectBank 

25 Systems Out Box for pick-up, it copies the object, 

26 decrypts and decompresses the object, and writes it to the 

27 designated ObjectSafe (either a file or in an OLE aware 

28 application file) where the user may then access and 

29 manipulate the object in whatever manner desired. Once 

30 the object has been successfully withdrawn ("picked- 

31 up\copied\retrieved") by the user, the Index Card of the 

32 object is updated and a successful retrieval message is 

33 placed in the Message Exchange Database. When the target 

34 ObjectWire Program sees the acknowledgement of the 

35 retrieval and that request message no longer exists, it 

36 updates the Index Card with the successful retrieval 

37 information. If the request message is not removed, the 

38 object stays in the target ObjectBank System's Out Box for 



3 
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1 a fixed period of time or until deleted by the ObjectBank 

2 Manager . 

3 Note that during this process no computer has written 

4 to another computer's disk and there has been no tampering 

5 with the object that was originally stored because the 

6 user does not have access to the stored object. The user 

7 only works with copies of objects, and cannot access the 

8 ObjectSafe directly. The object is left in the ObjectBank 

9 Out Box until the user's ObjectWire Program picks up the 

10 copy. If the user's computer inadvertently goes off line 

11 through a power failure or computer crash, the transfer 

12 will not be affected. When the user's computer comes back 

13 on line, the user's ObjectWire Program can access the 

14 ObjectBank Out Box and pick up the object. 
15 

16 DETAILED DESCRIPTION OP THE BEST MODE: 

17 Pig. 1 shows a schematic of a plurality of computers 

18 2, 2a, 2b, 3 and 3a each having an ObjectBank System of 

19 this invention and arranged in an exemplary ObjectWire 

20 Network 1 configuration. The ObjectWire Network 1 shows 

21 by way of example the capability of any computer having an 

22 ObjectBank System, whether a stand alone personal computer 

23 2, 2a, 2b or networked computer 3 r 3a, to share objects on 

24 an asynchronous, peer to peer basis with any other stand 

25 alone or networked computer on the ObjectWire Network 1 

26 having an ObjectBank System. There is no limit 16a, b to 

27 the number of ObjectBank System computers which may 

28 connect to each other via modem, LAN, WAN or other 

29 connecting means and thereby comprise the ObjectWire 

30 Network X. 

31 Each ObjectBank System computer 2, 2a, 2b, and 

32 networked computers 3 and 3a of Pig. 1, comprises a 

33 standard industry computer having in addition to its 

34 operating system, peripheral input /output devices and 

35 applications programs, the "ObjectTeller" program 4 and 

36 the "ObjectWire" program 5, and an object storage device 

37 (6, 7, 8, 9 and 10), called an "ObjectSafe" (6, 7, 9 and 

38 '10) 6r "ObjectVault" (6). While under certain 

39 circumstances it is preferred that each ObjectBank System 
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1 computer have its own ObjectSafe, depending on the 

2 intended use of the computer (s) or networked computer (s) 

3 on the objectWire Network, it is not required that each of 

4 the computers have its own object storage device because 

5 ObjectBank System computers can share an ObjectSafe with 

6 that of another ObjectBank System computer. For example, 

7 computer 2a need not have its own ObjectSafe 7 because it 

8 could use computer 2's, 3's or 3a 's ObjectSafe. Likewise, 

9 in existing network configurations 3 and 3a, individual 

10 work stations 11 and 12 do not require their own 

11 ObjectSafes, if file servers 13 and 14 include an 

12 ObjectSafe 9 and 10 or an ObjectSafe outside the network 

13 is used. Thus, if desired, all computers on the 

14 ObjectWire Network could be configured like an existing 

15 client-server configuration whereby all computers would 

16 share one computer's ObjectSafe. Computer 2b is 

17 configured such that it has an Object Vault 8 rather than 

18 an ObjectSafe. An ObjectVault is an ObjectSafe which has 

19 been configured to store a copy of all objects on the 

20 ObjectWire Network whereas an ObjectSafe is configured by 

21 a user to store only select objects on the ObjectWire 

22 Network. Therefore, any reference herein to an ObjectSafe 

23 may interchangeably be referred also to as an ObjectVault 

24 depending on the desired user configuration. It is 

25 preferred that at least one computer on the ObjectWire 

26 Network include an ObjectVault and that this computer be 

27 physically secure 15 from access by all persons except a 

28 designated ObjectBank Manager responsible for the 

29 operation and maintenance of the ObjectVault computer. 

30 Each ObjectSafe (6, 7, 9 and 10) and ObjectVault (8) 

31 is custom configurable. A typically envisioned 

32 configuration for each ObjectBank System's ObjectSafe disk 

33 directory would include the following subdirectories: 

34 Root Directory, DOS, Windows, Network Programs, Other 

35 Application Programs (may be accessible on the ObjectWire 

36 Network), ObjectBank Programs, ObjectSafe Configuration, 

37 ObjectTeller - User Interface, ObjectWire - Network 

38 Interface, ObjectBank Work Area, ObjectBank Message. 

39 Exchange Database, ObjectBank Out Box (read-only on the 
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1 network) , ObjectSafe Indexes (certain selected indexes) , 

2 and ObjectSafe Objects with the following two optional 

3 subdirectories: Temporary Object File, Permanent Object 

4 File. A typically envisioned ObjectBank System 

5 ObjectVault computer disk directory would include the 

6 following subdirectories: Root Directory, DOS, Windows, 

7 Network Programs, ObjectBank Programs, ObjectVault 

8 Configuration, ObjectWire - Network Interface, ObjectBank 

9 Work Area, ObjectBank Message Exchange Database, 

10 ObjectBank Out Box (read-only on the ObjectWire Network) , 

11 ObjectVault Indexes (all objects, all object indexes), and 

12 ObjectVault Objects having the following two 

13 subdirectories: Temporary Object File and Permanent 

14 Object File. 

15 Each ObjectBank System computer manages objects by 

16 indexing, depositing ("storing") , withdrawing 

17 ("retrieving") and communicating objects through the 

18 functions of the ObjectTeller and ObjectWire programs 4 

19 and 5. The ObjectTeller and Object Wire programs are 

20 written in "C" language and are capable of being 

21 constructed by one skilled in the art of computer 

22 programming using standard industry routines. The 

23 ObjectTeller program 5 is a menu driven user interface 

24 program for the configuration and use of the ObjectBank 

25 System, i.e., the depositing and withdrawing of objects, 

26 and for determining the status of the deposits and 

27 withdrawals of objects. The ObjectWire program 4 is a 

28 communications program having its own conf iguration and 

29 function files for the posting and withdrawal of objects 

30 to and from the other ObjectBank System computers on the 

31 ObjectWire Network 1. The functions of the ObjectTeller 

32 and ObjectWire programs can be accessed directly by 

33 executing each program independently of any other program. 

34 However, the functions of the ObjectTeller and ObjectWire 

35 programs are preferably accessed and executed indirectly 

36 through an OLE aware program operating within a Microsoft 

37 Windows operating environment. This preferred usage 

38 precludes the user from having to exit an applications 
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1 program to directly access and execute the functions of 

2 the ObjectTeller and ObjectWire programs. 

3 

4 THE OBJECTTELLER PROGRAM: 

5 The ObjectTeller program 5 comprises functions to 

6 permit a user means for processing the deposit and 

7 withdrawal of objects to and from one or more ObjectSafes 

8 (6, 7, 9 and 10) and/ or ObjectVaults (8) on the ObjectWire 

9 Network l, and review the status of deposits and 

1 0 withdrawa 1 s . 

11 Pig. 2 is a flowchart diagram of the configuration 

12 routine of the ObjectTeller program 5 of Pig. 1. Upon 

13 initial execution 101 and any subsequent execution of the 

14 ObjectTeller program, the ObjectTeller Configuration 

15 initialization file (ObjectTeller.ini) is read and saved 

16 in a temporary object, a local MED and ObjectSafe is 

17 opened, an array for each available ObjectVault and 

18 ObjectBank is built, and arrays for the User Data and 

19 Index Card Templates are built. If an error occurs, then 

20 the user is returned to the system. 

21 Then, a user or ObjectBank Manager has the option to 

22 custom configure the ObjectBank System by selecting and 

23 executing various options from a menu. The conf iguration 

24 routine permits the user (or ObjectManager) to: (1) select 

25 and change 102 the ObjectSaf e(s) and/ or ObjectVaults to 

26 which objects are to be deposited to or withdrawn from 

27 (the "target" ObjectSafe or ObjectVault); (2) select and 

28 change 107 which users are authorized to deposit or 

29 withdraw objects from an ObjectSafe and what level of 

30 access each user is permitted; and, (3) select and change 

31 110 which Index Card Template is to be used to record 

32 object information. 

33 1. Change ObiectSaf e/ ObjectVault : 

34 Referring further to Fig. 2, if a user (or 

35 ObjectManager) desires to select or change a target 

36 ObjectSafe (or ObjectVault) , he executes from a menu the 

37 ChangeObjectSafe function 102. This causes invocation of 

38 the file "SAFE. dig" file which includes the ObjectSafe and 

39 ObjectVault configuration information. Then, the 
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1 objectBanks and objectvaults known to this objectTeller 

2 are listed and the current target ObjectSafe and 

3 ObjectVault are indicated. The user then selects 103 from 

4 the list of logical devices which . ObjectSafe and 

5 ObjectVault is to be the current ObjectSafe and 

6 ObjectVault. The selection identifies the path to the 

7 desired target ObjectSafe or ObjectVault. Once the 

8 current target ObjectSafe and Objectvaults are selected 

9 103, the user can then select 104 to change the size and 

10 type of storage (i.e., ObjectSafe or ObjectVault), if 

11 desired. 

12 to make a change, the user first selects the 

13 ObjectSafe or ObjectVault from the SAFE.ini file and then 

14 selects to remove the ObjectSafe or ObjectVault from the 

15 SAFE.ini file or to change its parameters. If removal is 

16 desired, the selected ObjectSafe or ObjectVault is removed 

17 from the SAFE.ini file. If a change is to be made, an 

18 ObjectSafe/ObjectVault maintenance form is presented and 

19 the existing safe/ vault parameters are listed. The use 

20 then modifies the parameters. The parameters peculiar to 

21 the selected logical device are verified. If verified, 

22 then the user accepts or rejects the changes. If a change 

23 to the size and storage type is not desired, the user can 

24 then select 105 which other ObjectBanks systems are to be 

25 notified of object deposit and withdrawal activity. This 

26 is accomplished by selecting the target Objectsafes and/ or 

27 Objectvaults from the SAFE. dig file. The new targets are 

28 evaluated and the pathways validated. If validated 

29 successfully, a list of the available storage and types of 

30 storage registered for the ObjectSafe are listed. 

31 After the user completes any changes of Objectsafes 

32 or Objectvaults 102, selects the logical device for safe 

33 work 103, changes size or storage types 104, and/or 

34 selects the notification options 105, the bbjectBank 

35 system's configuration file database ("OBJBANK.INI"), is 

36 updated 106 to record the changes. 
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1 2. Change U ser Data: 

2 Referring further to Pig. 2, if a user desires to add 

3 new and/or change authorized users of the ObjectBank 

4 System, the user selects from a menu the changeUserData 

5 function 107, the AddNewUsers function 108 and/or selects 

6 the ChangeExistingUser function 109. 

7 If the user selects AddNewUsers 108, a maintenance 

8 template (form) is presented for completion by the user. 

9 The user must input certain minimum information such as 

10 the new users name, user type (i.e., depositor or 

11 borrower) , user description (i.e., a general comment), the 

12 unique user identification ("ID")', and the user's main 

13 storage "bank" (i.e., ObjectSafe) . Additional optional 

14 information may be input, such as, type of "bank account", 

15 any co-users, correspondent banks for this user, the user 

16 generation, short name, government identification number, 

17 visibility indicator, primary operating "branch" (i.e., 

18 home directory/pathway), date account opened, and 

19 permissible activities. The completed maintenance 

20 template is then verified and either accepted or rejected 

21 by the user and upon either of which the user moves on to 

22 ChangeExistingUsers function 109. 

23 if the user desires to change an existing user, 

24 he/she selects ChangeExistingUsers 109, which causes a 

25 list of existing current ObjectBank users to be displayed. 

26 The user selects from the list the user to be changed and 

27 that selected user's current information is displayed in 

28 a maintenance template form. The user completes the 

29 changes and either verifies or rejects the changed 

30 information. 

31 Once the user adds any new users 108 or makes any 

32 change to the existing users 109 and the changes are 

33 verified, accepted or rejected, the ObjectBank System's 

34 configuration database file OBJBANK.INI is updated 106 to 

35 record the additions or changes. 

36 3. Change Index Car d Template: 

37 . if a user desires to add new or change the Index Card 

38 Templates to which object index information will be 

39 recorded, the user selects from a menu the 
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1 changelndexCardTemplates function 110, then AddTemplates 

2 11X or ChangeTemplates 112 functions. 

3 If AddTemplates 111 is selected, a template 

4 maintenance form is presented and the user inputs certain 

5 minimum information such as the template name and class, 

6 the data type, the application type, and general usage 

7 description. Additional optional information may also be 

8 input such as the short name of the template, referenced 

9 bank accounts and the review date of the template. The 

10 added template is then verified and either accepted or 

11 rejected. If accepted, the new template is retained for 

12 subsequent updating of the OBJBANK.INI configuration file. 

13 Once the new template is either accepted or rejected, the 

14 system goes to the ChangeTemplates function 112. 

15 If tne US er does not desire to change a template, the 

16 OBJBANK.INI configuration file is updated. If the user 

17 desires to change a template, the ChangeTemplates function 

18 112 causes a list of the current bank templates to be 

19 presented. The user then selects which template is to be 

20 changed and the template with current information is 

21 displayed in standard template maintenance form. The user 

22 changes the desired information (i.e., completes the 

23 form) . The information is then verified and either 

24 accepted or rejected. If accepted, a new template with 

25 the changed information is retained for updating the 

26 OBJBANK.INI configuration file. If accepted or rejected, 

27 the OBJBANK.INI file is then updated 106. Once the 

28 OBJBANK.INI file has been updated 106 and no further 

29 objectTeller configuration changes or additions 102, 107, 

30 or 110 are desired, the ObjectTeller configuration routine 

31 is terminated by selecting 113 an exit function 

32 (StopObjectTellerConf iguration) . The user is then 

33 returned to the operating system environment from which he 

34 began prior to execution of the configuration routine. 

3 5 pig. 3 is a flowchart diagram for the ObjectTeller 

36 program deposit routine 200. To deposit an object in a 

37 ..' target Ob jectSafe, the. user .selects and executes 201 from 

38 a menu the ObjectTeller Deposit routine. Upon selection, 

39 the objectTeller.ini file is read and saved in a temporary 
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1 object. The local Message Exchange Database (MED) and 

2 local ObjectSage are opened and arrays for the available 

3 ObjectVaults, ObjectBanks, user data, and index card 

4 templates are built. In addition, the OTdep.dlg 

5 (ObjectTeller deposit menu) file is invoked. 

6 i. Rflleet a Target ObiectSafe 202 . Upon selection 

7 201 of the deposit function, the SAFE. dig (ObjectSafe and 

8 ObjectVault configuration) file is also invoked and the 

9 objectsafes and ObjectVaults known to this ObjectTeller 

10 are listed and the current target ObjectSafe and 

11 ObjectVault are indicated. The user then selects 202 the 

12 target ObjectSafe from his\her own ObjectSafe (if computer 

13 resident) and/ or one or more other Objectsafes on the 

14 objectWire Network l to which he\she has been authorized 

15 access. The user can select multiple target objectsafes 

16 if objects are desired to be deposited in several 

17 objectsafes. 

18 2 . Tdentifv the obier -trs! to be deposited 203. If 

19 the user desires to deposit an object from within an OLE 

20 environment (i.e., selects a "save" function within an OLE 

21 aware applications program) , the objectBank System reads 

22 each object and attempts to identify the type of object — 

23 WordPerfect, Dbase, Lotus, CAD, etc. If the user has not 

24 accessed the ObjectTeller functions through an OLE aware 

25 applications program, the user must identify/select the 
object (s) that will be deposited. The user can also 
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27 select whether the object to be deposited is temporary or 

28 permanent. If no object is identified for deposit through 

29 an OLE aware application, an object identification card 
3 0 (template) is presented to the user for completion. The 

31 user then inputs 203 certain minimum object identification 

32 information such as the object name, object type and 
object location. Wildcard characters (e.g., ?, /, *) may 
be used. If the user does not input the object type, the 
ObjectTeller deposit routine will evaluate and 

36 automatically select the object type. If the user does 

37 not input the object location, a list of default paths is 

38 presented allowing the user to select between directories 

39 and drives. 



33 
34 
35 
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! 3. Fill-out: object Index Card 204 . Once the object 

2 identification card is completed 203, the deposit function 

3 locates the identified object and evaluates its type and 

4 verifies it against the user's indication or (if no user 

5 indication of type) , the deposit function automatically 

6 identifies and classifies the type of the identified 

7 object. The ObjectTeller program creates a user index 

8 card from a default index card template for each type of 

9 object, partially completes the index card with minimum 

10 data from the object for identification and storage, then 

11 displays the index card to the user for completion 204. 

12 If the object has previously been deposited in the 

13 ObjectBank System, then a list of all the previous 

14 relative index cards is presented which identify any 

15 related object (s) (i.e., "parents," "children" or 

16 "siblings") . The user can retrieve and look at the index 

17 cards for these parent /children /siblings objects and do an 

18 on-screen object comparison before deciding whether to 

19 continue with the depositing of the object. The user can 

20 then select and examine the various index cards and either 

21 select one for the default model or request a new index 

22 card template having the minimum identification and 

23 storage data for the object to be deposited. The user 

24 then completes 204 the index card by inputting optional 

25 information such as co-users interested in this object, 

26 the object generation", an object alias, the visibility 

27 indicator, the primary object level, object creation or 

28 reference date, cross-reference keys within the object and 

29 cross-reference keys to other objects. In addition, the 

30 user indicates by inputting a check on the index card 

31 his/her choice for object encryption, compression, 

32 password access protection and/ or object deletion from the 

33 local ObjectSafe's subdirectory after deposit to the 

34 target ObjectSafe\ Vault. An index card is completed for 

35 each object to be deposited. 

36 4. Initiate Deposit Fiipr.tion 205. If the user 

37 desires to continue with . the deposit of the object, the 

38 ObjectSafe deposit function is initiated 205. The object 

39 index card data is placed in a structure and read to 
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1 determine if the object to be deposited is to be encrypted 

2 206 and compressed 208 before depositing. The default is 

3 to encrypt 207 and compress 209 the object before the 

4 object is deposited to a target ObjectSaf e\Vault. If the 

5 object is to be encrypted 207, the object is located, its 

6 size and storage requirements evaluated, then encrypted 

7 and the storage setup. If the object is be compressed 

8 209, the object is located, its size and storage 

9 requirements evaluated, then compressed and storage setup. 

10 5. Deposit object to local or non-local ObiectSafe 

11 210 . The ObjectTeller program then determines 210 if the 

12 object is to be deposited to the local (computer resident) 

13 ObjectSafe or to a non-local ObjectSafe located elsewhere 

14 on the ObjectWire Network 1. If the object is to be 

15 deposited in a non-local ObjectSafe, then the object and 

16 related index card is located, object accounting 

17 (tracking) information added, and the object placed 211 in 

18 the outbox for pick-up by the target ObjectSafe computer. 

19 A deposit request index card is placed 212 in the Message 

20 Exchange Database, and after which, the ObjectTeller 

21 deposit routine is terminated 218. 

22 6. Perform ObiectBank system error checking 213 . 

23 If the object is to be deposited in a local 

24 Ob jectSafe\ Vault, then the object is located and industry 

25 standard system error checking functions are performed 213 

26 including checksum validation on the source and altered 

27 object form, size and storage requirement evaluation and 

28 comparison to local target storage capacity, and the 

29 system clock switch is set and results conditions checked. 

30 The ObjectTeller program reads ("copies") each object into 

31 its "work area" RAM from the source object, then 

32 calculates checksums for data validation. It compares the 

33 object in the work area to the source object checksums to 

34 verify data transmission accuracy. It also checks to make 

35 sure there is sufficient space on the target ObjectSafe 

36 for the object to be deposited, so as not to exceed the 

37 pre-conf igured maximum ObjectSafe storage capacity. If an 

38 error is detected 217, then an ObjectDeposit error message 

39 template is created and placed 217 in the local Message 
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1 Exchange Database and the ObjectTeller Deposit routine is 

2 terminated 218. 

3 7. Denosit thp object to the t arget Objpr.l-.Saf e 215 

4 or indicate system error 217 . If the system error checks 

5 are successful and no error is detected 214, then the 

6 object is located, object accounting information added, 

7 and then deposited 215 from the work area RAM into the 

8 target objectSafe. The object index card is located in 

9 the work area RAM, object accounting information added to 

10 indicate a successful deposit location, then placed 216 in 

11 the local target ObjectSafe and in the Message Exchange 

12 Database with a public routing code ("flags") so all other 

13 ObjectSafe computers on the ObjectWire Network 1 can 

14 update their indexes. The ObjectTeller deposit routine is 

15 then terminated 218. 

16 If tne object is to be deposited in an ObjectSafe on 

17 another ObjectBank System computer on the ObjectWire 

18 Network 1, the source ObjectBank System ObjectWire program 

19 will keep polling the Message Exchange Database on the 

20 target ObjectSafe computer until a message appears that an 

21 updated index card for the deposited object appears 

22 indicating that the deposit was successful, its deposit 

23 location, and that an updated index card is available for 

24 pick up in the target ObjectSafe computer's Out Box. The 

25 updated index card is then copied from the target 

26 ObjectSafe' s Out Box to the source ObjectSafe. When 

27 successfully copied, the object will be cleared from the 

28 source Out Box and an Index Updated message, cross- 

29 referenced to the object, will be placed in the source 

30 ObjectBank computer's Message Exchange Database and routed 

31 to the target ObjectSafe. When a duplicate index updated 

32 message appears in the Message Exchange Database of the 

33 source ObjectSafe computer with the source user's routing 

34 code, the target ObjectBank system will clear its out Box 
3 5 of all information related to the object. If the user has 

36 indicated that the object should be moved/deposited to a 

37 Null Device, it .will be deposited to the Null . Device, and 

38 essentially deleted from the source ObjectSafe. 
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1 Pig. 4 is a flowchart diagram of the ObjectTeller 

2 program withdrawal routine 300 is shown having functions 

3 to withdraw an object from a target ObjectSafe\ Vault. A 

4 user withdraws objects by selecting and executing from a 

5 menu the ObjectTeller withdrawal routine 301. This causes 

6 the ObjectTeller.ini file to be read and saved in a 

7 temporary object. The local Message Exchange Database and 

8 local ObjectSafe are opened and arrays for the available 

9 ObjectSafes and ObjectVaults, user data, and index card 
10 templates are built. 

H i. complete Search Index Card for object index card 

12 search 302 . The first step in the withdrawal of an object 

13 from the ObjectBank System is to first identify the object 

14 and its location by conducting an object index card 

15 search. When executing the ObjectTeller withdrawal 

16 process routine 301, the ObjectTeller program invokes the 

17 Sindex.dlg file which displays a search index card having 

18 blank fields to be completed 302 by the user. The user 

19 then completes the fields which designates which 

20 ObjectSafes are to be searched and what object and/or type 

21 of object index card is to withdrawn from the designated 

22 target ObjectSafes. The more search criteria input on the 

23 Search Index Card, the more inclusive and narrower the 

24 search for a particular object or type of object Index 

25 card. If the user cannot type entries in the search 

26 fields, then clicking upon the fields causes a list to be 

27 presented showing available selections for the selected 

28 search criteria. 

29 Once the search criteria is input/ selected 302, the 

30 ObjectTeller withdrawal routine parses the completed 

31 search fields and sets up a search criteria database. A 

32 fuzzy search of the index cards of the designated local 

33 ObjectSafe is then performed 303 matching the Search Index 

34 Card to the desired object(s) index card. The matching 

35 index cards are collected in an array and displayed 304 in 

36 a list format for review by the user. The ObjectBank 
. 37 system reports how many index cards have been found, with 

38 an exact match and how many with a "fuzzy" match. If a 

39 matching index card has not been found in the local 
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1 objectsafe(s) (e.g., as a result of the object being 

2 deposited to an ObjectVault and removed from the local 

3 ObjectSafe in order to save disk space) and a search of 

4 additional Index Cards is desired 305 f then the user can 

5 request a withdrawal of object index card(s) from an 

6 ObjectVault and /or other ObjectSafes on the ObjectWire 

7 Network 1 and an index card withdrawal request will be 

8 placed in the Message Exchange Database 306. The user is 

9 allowed to select for searching other ObjectSafes on the 

10 ObjectWire Network to which he has been authorized access. 

11 The user can select multiple target ObjectSafes if the 

12 desired object (s) may have been deposited in several 

13 ObjectSafes on the ObjectWire Network. Any additional 

14 found index cards returned by the request will be 

15 displayed 304 in the list format for review by the user. 

16 If the user determines he has not found the desired 

17 object (s) , he can change 307 the search criteria and fill- 

18 out another Search Index Card and another object index 

19 card search process can be performed 303 and the results 

20 of the search displayed 304. 

21 2. Select the index card of the object to — be 

22 withdrawn 308 . To view an index card of the object to be 

23 withdrawn, the user selects 308 the desired index card 

24 from the displayed list. By selecting 308 the index card 

25 to be viewed, the ObjectTeller withdrawal routine parses 

26 the ObjectBank account , • type and location data so the user 

27 can see the detail of the index card, including 

28 information on the genealogy and pathway of who has 

29 deposited and who has withdrawn the object. The user can 

30 also look at the index cards for the 

31 parents/children/siblings before deciding whether to 

32 continue. 

33 3. Initiate the with drawal function 309. To 

34 withdraw one or more objects identified on the index 

35 cards, the user initiates the ObjectSafe withdrawal 

36 function by selecting 309 the desired object to be 

37 withdrawn . . This causes the index card .data to be placed 

38 in the search structure. It should be noted that if the 

39 user is not accessing the ObjectTeller program through an 
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1 OLE environment, the user must indicate to which drive, 

2 directory, and filename the object will be copied 

3 (withdrawn to) . If nothing is entered, then a directory 

4 display will appear allowing the user to highlight certain 

5 drives and directories. If the user is retrieving 

6 temporary information, he has the option of indicating 

7 that the information should be deleted from the source 

8 ObjectSafe after successful withdrawal into the work area 

9 RAM. 

10 4. P^rfnm sv °tP M p-rror r^nlHna 310. Once the 

11 ObjectSafe withdrawal function is initiated 309, the 

12 object size is determined and formed in an index structure 

13 and System error checking is performed 310 evaluating the 

14 reguired size and storage and comparing it to the local 

15 target ObjectSafe\ Vault capacity so as not to exceed the 

16 pre-configured maximum storage capacity. If an error is 

17 detected 311, an ObjectWithdrawal error message is created 

18 and placed 312 in the Message Exchange Database and the 

19 objectTeller withdrawal routine is terminated 319. 

20 5. n.tPrmine l o ~»Htv of ohipnt to be withdrawn , 

21 111- If no System error is detected 311, the 

22 ObjectTeller program determines if the object(s) to be 

23 withdrawn are to come from a local ObjectSafe or an non- 
24 local ObjectSafe 313. 

25 if the withdrawal is to be made from a non-local 

2 6 ObjectSafe (i.e., an other ObjectBank System having an 

27 ObjectSafe or ObjectVault) a withdrawal reguest with the 

28 correspondent information and flags to alert the target 

29 ObjectSafe (object -source" ObjectSafe) is placed in the 

30 Message Exchange Database 314. The ObjectTeller 

31 withdrawal routine is then terminated 319 and the 

3 2 ObjectWire program polling routine will begin cyclically 
3 3 polling the target ObjectSafe (s) Message Exchange Database 
34 to detect when the desired object is ready to be picked-up 
3 5 from the target ObjectBank computer's Out Box 601 (see 
3 6 Fig. 7). 

37 6. Withdraw ^hiect. fr m local Ohj f.ctSafq 31S. If 

38 it is determined 313 that the withdrawal is to be made 

39 from a local ObjectSafe, the object is located in the 
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1 local ObjectSafe and read ("copied") 315 into the local 

2 work area RAM. If necessary, the withdrawn object is 

3 decompressed and decrypted 316. 

4 The withdrawn object is then located in the local 

5 work area RAM, the target location where the object is to 

6 be deposited is verified, and the copy of the object 

7 deposited in accordance with the deposit function 205 (see 

8 Pig. 3) to the target objectSafe\ Vault. 

9 The index card for the object withdrawn is then 

10 updated with the accounting and time information and 

11 placed 318 in the Message Exchange Database for pick-up 

12 and notification of the source ObjectSafe computer and 

13 update of it's object index card that the transaction was 

14 completed. Once the index card of the source ObjectSafe 

15 is updated and a message placed in the Message Exchange 

16 Database, the ObjectTeller withdrawal routine is 

17 terminated 319. It should be noted that if the 

18 withdrawal is made from a non-local ObjectSafe, then an 

19 Updated Index card message will be placed in the source 

20 ObjectBank Message Exchange Database indicating that the 

21 source ObjectBank 's index card has been updated and the 

22 Out Box cleared. When the requesting ObjectBank 

23 computer's ObjectWire program detects the Updated Index 

24 Card message, it will clear its Message Exchange Database 

25 with regard to that withdrawal transaction. 

26 Fig- 5 is a flowchart diagram of the ObjectTeller 

27 program's Status process routine 400 having functions to 

28 allow the user to review the status of object deposits and 

29 withdrawals and to terminate in-process deposits and 

30 withdrawals, if desired. 

31 Referring now to Pig. 5, to determine the status of 

32 withdraw or deposit or to terminate a withdrawal or 

33 deposit, a user selects 401 from a menu the ObjectTeller 

34 Status process routine. This causes the ObjectTeller.ini 

35 file to be read and saved in a temporary object. In 

36 addition, the local Message Exchange Database is opened. 
37. The local Message Exchange Database is checked 402 

38 for any changes, i.e., whether or not a new message has 

39 been added or an old message has been deleted since the 



WO 94/14127 W W PCT/US93/1186S 

-33- 

1 last recorded date-time-stamp. Each time the Message 

2 Exchange Database is checked, a date-time-stamp ("DTS") is 

3 recorded and the last DTS is read for access checking. A 

4 "DTSKEY" is used to access the Message Exchange Database 

5 messages. If no change is detected 403 since the last 

6 DTS, the Status function continues to check the local 
Message Exchange Database until a change is detected. 

8 once a change is detected 403, a new DTSKEY will be stored 

9 and the type of message change (i.e., index card or 
deposit or withdrawal request message) is determined 404. 

12 _ if the change is an index card message or a deposit 

12 or withdrawal request message, an acknowledgement flag is 

13 checked 406 to determine if the request is still in 

14 process. If acknowledged, the deposit or withdrawal 

15 request is complete and the object deleted 407 from the 

16 Message Exchange Database, the index card is stored 408 in 

17 the Message Exchange Database, and a handling message is 
setup and presented 405 to notify the user of the present 



7 



10 



18 



19 status. If not acknowledged, the request is still in 

20 process and the index card is stored 408 in the Message 

21 Exchange Database and a handling status message is setup 

22 and the user presented 405 with the present status. 

23 if the message determined 404 is not an index card or 

24 deposit or withdraw request, an error message is created 

25 and the handling status message is setup and presented 405 

26 to the user. 

27 Once the user has been notified of the present status 
405, obsolete messages can then be removed from the 



28 



29 Message Exchange Database 409 (as necessary) and stored in 

30 the local Objectsafe and a user notification list setup. 

31 If the user desires to continue checking the status of 

32 deposits and withdrawals, the local Message Exchange 

33 Database is polled 410 for changes as before. If the user 

34 does not desire to continue checking the status of 

35 deposits and withdrawals, the Status function is 

36 terminated 411. 

37 . The pbjectwire program 4 (Pig. D comprises functions 
to permit a user to communicate' between two or more 
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39 ObjectBank Systems (e.g., 2, 2a, 2b, 3, and 3a) to process 
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1 the deposit and withdrawal of objects to and from one or 

2 more ObjectSafes (6, 7, 9 and 10) and/or objectVaults (8) 

3 on the objectwire Network 1. 

4 pig. 6 is a flowchart diagram of the Objectwire 

5 program configuration routine 500. The Objectwire 

6 configuration routine permits the user to custom configure 

7 at any time which objectBank Systems (ObjectSafes) on the 

8 Objectwire Network are to be polled 502, which ObjectBank 

9 Systems are not to be polled 507, how the ObjectBank 

10 System to be polled is accessed 504, when the selected 

11 ObjectBank Systems are to be polled 505, and also to 

12 change the criteria of the objects (Index card, Index Card 

13 Message or Object) to be polled 510. 

14 The Objectwire configuration routine is accessed and 

15 executed by way of menu selection via the ObjectTeller 

16 program 5 (Fig. 1) . Upon the execution of the Objectwire 

17 configuration routine 501, the ObjectTeller.ini file is 

18 read and saved in a temporary object, the local Message 

19 Exchange Database and local Objectsafe are opened, and 

20 arrays for the available ObjectSafes and ObjectVaults, 

21 user data, and index card templates are built. In 

22 addition, the "Ow.dlg" (Objectwire configuration menu) 

23 file is invoked. 

24 The user has the option of menu selecting the 

25 ObjectSafes to be polled 502, to select those ObjectSafes 

26 which are not to be polled 507 and to change the item 

27 (i.e., index card, message and/or object) criteria to be 

28 polled 510. 

29 if the user selects the ObjectSafe(s) to be polled 

30 list (Change Do Poll List) 502, the SAFE. dig file is 

31 invoked and the ObjectSafes and ObjectVaults known to this 

32 ObjectTeller are listed and the current target Objectsafe 

33 and Objectvault indicated. The user then selects 503 from 

34 the list those ObjectSafes to which the user is permitted 

35 access. 

36 After an Objectsafe is selected 503 to be polled, the 

37 "SAFENAV.dlg" (Objectsafe navigation information) file is 

38 invoked and the user inputs 504 the manner (i.e., pathway 

39 and procedure: address /telephone, number /password, etc.) 
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by which the target objectsafe is to be accessed, 
the user inputs 504 how the target ObjectSafe can be 
accessed, the user inputs 505 the time interval upon which 
the target objectsafe is to be polled or accepts the 
5 default (ObjectTeller.ini) interval. When the user has 
completed selecting 503 the target Objectsafe (s) to be 
polled and inputting how 504 and when 505 the target 
8 Objectsafe(s) are to be polled, the ObjectWire 
configuration database file OBJBANK.INI is updated 506. 
The user is then returned to the beginning of the same 
option of whether or not to change the ObjectSafe polling 

12 list 502. 

13 If the user no longer desires to change 502 the 

14 Objectsafe polling list, then the user has the option of 

15 selecting 507 from a menu those ObjectSafes that are not 

16 to be polled 507. If the user selects 507 to change the 

17 ObjectSafes not to be polled, then the SAFE. dig file is 

18 invoked, the ObjectSafes and ObjectVaults known to this 

19 ObjectTeller are listed and the current Objectsafe and 

20 ObjectVaults are indicated. The user then selects 508 

21 from the list the desired Ob jectSafes\ Vaults that are not 



ObjectSafes\Vaults as "NOTPOLL . " After the ObjectSafes 
are marked 509, the ObjectWire configuration database file 
OBJBANK.INI is updated 506. The user is then returned to 
the beginning of the option of whether to change the 
Objectsafe polling list 502; if not, then to the change 
the do not poll list; and, if not, then the user has the 
30 option of changing 510 the items to be polled. 

If the user chooses the menu option to change 510 the 
items to be polled, the user is presented with a list of 
polling items, i.e., the user can select 511 the index 
card or message criteria to change. The selection tabs 
3 5 on/ off an index card/message awareness switch. Once the 
desired item criteria has been changed 511, the user is 
presented with a polling object list from which he/she can 
select to change 512 the object or type of object criteria 
to be polled, in addition, the user can also enter a new 
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1 object type to be included in the polling criteria, once 

2 the user selects 512 the object criteria to be changed 

3 and/or enters the new object type to be included in the 

4 polling criteria, the Objectwire configuration database 

5 file is updated 506. The user is then returned to the 

6 beginning of the option of whether to change the 

7 Objectsafe polling list 502; if not, then to the change 

8 the do not poll list; if not, then the user has the option 

9 of changing 510 the items to be polled; if not, then the 

10 Objectwire configuration routine is terminated 513. The 

11 user returns to the objectTeller program 5 (Fig. l) menu 

12 operating environment. 

13 Pig. 7 is a flowchart diagram of the objectwire 

14 program polling routine 600. The objectwire program 

15 polling routine operates continuously in the background in 

16 a Microsoft Windows® type OLE operating environment and is 

17 also manually executable by menu selection via the 

18 ObjectTeller program 5 (Pig. 1) - Upon execution 602, the 

19 ObjectTeller.ini file is read and saved in a temporary 

20 object, calls are made for available servers on each 

21 adapter installed in the ObjectBank System and then 

22 listens for broadcast signatures of network servers. If 

23 a server is found 603, the OBJBANK.INI database file is 

24 updated 604 with the server information (pathway, 

25 telephone number, password, etc.) and the server is added 

26 to the presently available polling list. 

27 Then, as configured by the Objectwire Configuration 

28 routine 501, the Objectwire Polling routine cyclically 

29 polls 605 target ObjectBank Systems (servers) at a given 
time. Each time an ObjectBank System is polled, a date- 
time-stamp ("DTS") is recorded. If it is not time to poll 
605 a given target ObjectBank system, a user has the 

33 option of having the objectwire polling routine continue 

34 polling 606 and listen 602 for Network servers or the 

35 polling routine can be terminated 607 and the user 

36 returned to the menu operating environment of the 

37 ObjectTeller program 5 (Pig. 1) . If it is time to poll 

38 605 a given target Objectsafe System, the Objectwire 

39 polling routine will check 608 to see if the Objectbank 
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1 System is "logged-on" to the target Objectbank System. If 

2 the ObjectWire Polling routine detects 608 that the 

3 Objectbank System was logged-on, then the logical device 

4 is redirected 610 to the target ObjectBank System's 

5 ObjectSafe (server) location, the last DTS for this server 

6 is read and the Message Exchange Database is opened for 

7 this server. If the Objectbank System was not logged on 

8 608, the ObjectWire Polling program will log-on 609 to the 

9 target ObjectBank System, set 609 a flag called 

10 "WasLogged" to equal "false," set a flag called "LogOn" to 

11 equal "yes," and then redirect 610 the logical device to 

12 the target ObjectSafe. Once the logical device has been 

13 redirected 610 , the ObjectWire polling routine determines 

14 611 if there are any messages put in the Message Exchange 

15 Database since the last DTS. If there are no messages 

16 since the last DTS and the "WasLogged" flag is set to 

17 "false," then the ObjectWire Polling routine logs-off 612 

18 the server and sets the LoggedOn flag equal to "no." The 

19 ObjectWire Polling routine returns to the polling process 

20 at step 605 (Time to Poll any Servers) . If there is one 

21 or more messages since the last DTS 611, then the 

22 ObjectWire Polling routine determines 613 if any message 

23 matches the search criteria as set during the ObjectWire 

24 Configuration process 501-513 and what type 614 each 

25 message is, i.e., a withdrawal request, deposit request or 

26 index card message. If the message is a withdrawal 

27 request, the ObjectTeller withdrawal routine function 

28 (309) is performed 615 to the Outbox and the ObjectWire 

29 polling routine continues 606. If the message is a 

30 deposit request, the object is read and the ObjectTeller 

31 deposit function (205) is performed 616 and the ObjectWire 

32 polling routine continues 606. If the message is an index 

33 card message, then it is determined 617 whether or not the 

34 message is one that originated from this ObjectBank System 

35 617. If yes, i.e., it is a message originating from the 

36 local ObjectBank, then it is an acknowledgment of a 

37 deposit or withdrawal request and it is read and stored 

38 618 in the local Message Exchange Database for. further 

39 processing, and the ObjectWire Polling routine continues 
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1 606* If the message did not originate from this 

2 ObjectBank System, then the message is read and stored 619 

3 in the local Message Exchange Database for further 

4 processing. If an object is associated with the message 

5 and the object is in the ObjectBank System's read area, 

6 the object is read and stored in the temporary storage 

7 area of the objectSafe, and the ObjectWire Polling routine 

8 continues 606 until terminated 607. 

9 pig. 8 is a flowchart diagram of the ObjectWire 

10 program Withdrawal routine 700. The ObjectWire program 

11 withdrawal routine operates 701 continuously in the 

12 background in an OLE operating environment and is also 

13 manually executable by menu selection via the ObjectTeller 

14 program 5 (Fig. 1) . The ObjectWire withdrawal routine 

15 looks 702 for any withdrawal or index card requests in the 

16 local Message Exchange Database. If none are found, the 

17 user has the option 703 of continuing to look 702 for 
local withdrawal or index card requests or terminate 704 
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19 the ObjectWire withdrawal routine which returns the user 



20 



to the operating menu environment of the ObjectTeller 

21 program 5 (Pig. l) . If a withdrawal or index card request 

22 is found 702 in the local Message Exchange Database, then 

23 the ObjectWire withdrawal routine will check 705 to see if 

24 the Object bank System is logged-on to the source 

25 Objectbank System. If the ObjectWire Withdrawal routine 

26 detects 705 that the Objectbank System was logged-on , then 

27 the logical device is redirected 707 to the source 

28 ObjectBank System's ObjectSafe. If the Objectbank System 

29 was not logged-on 705, the ObjectWire Withdrawal routine 



30 



will log-on to the source ObjectBank System server, set 

31 706 the "WasLogged" flag to equal false, set the "Logon" 

32 flag to equal "yes," redirect 707 the logical device to 

33 the source ObjectSafe (server) location, and then open the 

34 ObjectSafe on this server. Once the logical device has 

35 been redirected and the ObjectSafe opened 707, the 

36 ObjectWire withdrawal routine locates the object size and 

37 form in the index structure, . evaluates its size and 
storage required and compares it to the local target 
capacity. If ok, the object is located in the 
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1 corresponding source ObjectSafe OutBox and read 

2 ("withdrawn" or "copied") into the local work area RAM 

3 708. The object is then located in the local work area 

4 RAM and decompressed and decrypted 709, if necessary. 

5 Then object is again located in the local work area RAM, 

6 the target ObjectSafe location verified, and the object 

7 copied 710 to the target location. After the object has 

8 been copied 710 to the target location, the withdrawal is 

9 acknowledged 711 by placing an Updated Index Card in the 

10 Message Exchange Database with the accounting and time 

11 information. After the withdrawal has been acknowledged 

12 711, if the "WasLogged" flag is equal to "false," then the 

13 ObjectWire withdrawal routine causes the System to logoff 

14 712 the server, set "Logon" to equal "no," and return to 

15 the option 703 of whether or not to keep looking for local 

16 withdrawal or index card requests 702 or to terminate 704 

17 the ObjectWire Withdrawal routine. 
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1 l. A highly secure, virus resistant, tamper 

2 resistant, object oriented, data processing system for 

3 depositing, withdrawing and communicating electronic data 

4 between one or more individual and/or networked computers 

5 comprising: 

6 a) at least one computer means for processing 

7 electronic data; 

8 b) at least one of said computer means including at 
least one or more shared electronic storage means for 
temporary or permanent storage of said electronic data; 

11 and 

12 C ) each of said computer means including program 

13 means for asynchronous deposition, withdrawal and 

14 communication of said electronic data to said shared 

15 electronic storage means. 

1 2. An object oriented data processing system as in 

2 claim 1, wherein said program means includes: 

3 a) means for user definable installation and 

4 configuration of said storage means and said program means 

5 to said system; 

6 b) means for archival, accountability, 

7 security, encryption and decryption, compression and 

8 decompression, and multi-processing of said electronic 

9 data; and 

10 C ) said electronic data is only deposited, 

11 withdrawn and communicated through copying of said data on 

12 said system. 

1 3. In a computer system comprising of one or more 

2 individual or networked computers, each of said computers 
including an object oriented user interface program, an 

4 object oriented communications program, and at least one 

5 of said computers having an electronic data storage means 

6 , haying a plurality of. specifiable regions, a method for 

7 peer to peer depositing/withdrawing and communication of 
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8 electronic data between said one or more individual or 

9 networked computers comprising the steps of: 

10 a) asynchronously depositing electronic data 

11 to said data storage means; 

12 b) asynchronously withdrawing electronic data 

13 from said data storage means; and 

14 c) asynchronously communicating between said 

15 computers said data to be deposited and withdrawn from 
said data storage means using said deposit and withdrawal 
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1 4. A method as in claim 3 wherein, said step of 

2 depositing electronic data includes the steps of: 

3 a) selecting one or more of said data storage 

4 means to which said data is to be deposited; 

5 b) identifying the data to be deposited to 

6 said selected data storage means as either temporary data 

7 or permanent data; 

8 c) creating a corresponding electronic data 

9 index and inputting to said data index reference 
10 information of said data to be deposited; 

xl d) determining the location of said selected 

12 data storage means to which said data is to be deposited; 

13 e ) storing said data to said storage means at 

14 said determined location; 

15 f) updating said data index with further 

16 reference information about said deposited data; and 

17 g) storing said updated data index in a first 

18 specified region of said data storage means for 

19 communication between said computers. 

1 5. A method as in claim 4, wherein said step of 

2 depositing electronic data further includes the steps of: 

3 a) storing said data to be deposited to a 

4 second specified region for communication between said 

5 computers using said communications routine; 

6 b) detecting a second updated data index 

7 indicating the data to be deposited has been successfully 

8 deposited to said selected data storage means; 
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9 c) encrypting said data to be deposited; and 

10 d) compressing said data to be deposited. 

1 6. A method as in claim 5 wherein said step of 

2 depositing electronic data further includes the steps of: 

3 a) performing system error checks prior in 

4 time to the depositing of said data to said data storage 

5 means ; and 

6 b) generating and storing any error message 

7 resulting from said system error checks in said first 

8 specified region of said storage means for communication 

9 to said plurality of computers. 

1 7. A method as in claim 3, wherein said step of 

2 withdrawing said electronic data includes the steps of: 

3 a) completing a second corresponding 

4 electronic data index card with reference information to 

5 be used in the conduct of a comparison search of said 

6 storage means for said first electronic data index cards 

7 having matching reference information to said electronic 

8 data to be withdrawn; 

9 b) conducting said comparison search to 

10 determine any said matching reference information to said 

11 completed second data index card; 

12 c) displaying said first data index cards 

13 having said matching reference information to said 

14 completed second data index card; 

15 d) selecting any of said first data index 

16 cards displayed identifying the data to be withdrawn; 

17 e) determining the storage location of said 

18 selected data index cards to be withdrawn and the location 

19 from which said identified data is to be withdrawn; and 

20 f) withdrawing from said determined location 

21 said identified data to random access memory of said 

22 computer system. 
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8. A method as in claim 7 wherein said step of 
withdrawing said electronic data includes the steps of: 
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3 a) placing a withdrawal request message in 

4 said second specified region for communication to any of 

5 said plurality of computers using said communications 

6 routine; 

7 b) performing said system error checks 

8 subsequent in time to said withdrawal of said electronic 

9 data to said random access memory; 

10 c) generating and storing any error message 

11 resulting from said system error checks in said first 

12 specified region of said data storage means for the 

13 communication of any said error message to said system and 

14 any of said plurality of computers; 

15 d) updating said first index card with 

16 information about said data withdrawn from said data 

17 storage means; 

18 e) storing said updated first data index card 

19 in said second specified region of said data storage means 

20 for communication to said plurality of computers by use of 

21 said communications routine; 

22 f) decompressing said withdrawn electronic 

23 data; and 

24 g) decrypting said withdrawn electronic data. 

1 9. A method as is claim 3 which comprises a status 

2 routine including the steps of: 

3 a) recording a date-time-stamp to said first 

4 region; 

5 b) checking said first specified region for 

6 data recorded to said first region subsequent in time to 

7 said date-time-stamp; 

8 c) determining the type of any of said 

9 changes ; 

10 d) determining if any of said determined types 

11 are still in process; 

12 e) deleting said types that are still in 

13 process; 

14 f) storing said data index card of types still 

15 in process in said first specified region; and 



WO 94/14127 W W PCT/US93/11865 

-44- 

16 g) updating said data index card with the 

17 present status and displaying said status. 

1 10- A method as in claim 9, wherein said step of 

2 communicating between said computers includes the steps 

3 of: 

4 a) determining and displaying a list of said 

5 computers available for communication with said system; 

6 b) selecting from said list the computers to 

7 be communicated with said system; 

8 c) inputting a cyclical time interval with 

9 which communication between said selected computers shall 
10 occur; 

xl d) recording to a configuration file for 

12 subsequent use by said system said selected computers and 

13 input time interval 

14 e) determining and displaying criteria to be 

15 communicated between said selected computers; and 
!5 f) inputting changes to said criteria. 

1 11. A method as in claim 3 wherein said step of 

2 communicating between said computers further includes the 

3 steps of: 

4 a) listening for the initiation of 

5 communications from any of said computers and adding the 

6 logical path of said computers initiating said 

7 communications ; 

8 b) cyclically initiating communications 

9 between said computers; 

10 C ) directing a logical device to said 

11 computers with which said communications have been 

12 initiated; 

13 d) determining the existence of messages 

14 subsequent in time to the last recorded of said 

15 communications between said computers; 

16 e) determining which of said messages includes 

,17 . matching data ; .. . 

18 f ) determining the type of said messages 

19 having said matching data; and 
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20 g) performing one of said steps of depositing 

21 said electronic data to said data storage means, 

22 withdrawing said electronic data from said data storage 

23 means, or reading and recording said messages to said 

24 storage means, according to the determined type of said 

25 messages. 

1 12. A method as in claim 3 wherein said step of 

2 communicating between said computers includes the steps 

3 of : 

4 a) cyclically determining the existence in 

5 said storage means of any request messages from any of 

6 said computers; 

7 b) initiating communications with said 

8 computers from which any of said request messages 

9 originated; 

10 C ) directing a logical device to said 

11 computers ; 

12 d) reading data from said computers; 

13 e) copying said data to said storage means; 

14 and 

15 f) decompressing and decrypting said read 

16 data. 
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